Method and apparatus for determining display element attribute values

ABSTRACT

A method for determining display element attribute values from an object represented by the display element includes defining a display element view including at least one elementary view that is capable of determining a display element attribute value, receiving a display element attribute value request, determining the first view for the display element and ascertaining at least one display element attribute value for the display element based upon the first view. An apparatus for determining display element attribute values from an object represented by the display element includes a definer to define a display element view including at least one elementary view that is capable of determining a display element attribute value, a receiver to receive a display element attribute value request, a determiner to determine the first view for the display element and an ascertainer to ascertain at least one display element attribute value for the display element based upon the first view.

FIELD OF THE INVENTION

The present invention relates to the field of computer science. Moreparticularly, the present invention relates to a method and apparatusfor determining display element attribute values.

BACKGROUND OF THE INVENTION

Software applications such as Graphical User Interfaces (GUIs) thatdisplay information about a program or a file system typically displaythe information using a particular display form. The system to bedisplayed is typically divided into objects that may be related to oneor more other objects. A display element is an object or element thatrepresents an object. The represented object may be any object used inthe system being represented, such as an application file, databaserecord or Java™ field. A display form determines how display elementsare displayed. Some typical examples of display forms include a treeform, a cascade form and a list form. Each display element has a set ofattributes that is determined by a particular display form; the set ofattributes is independent from the object that is represented by thedisplay element. These relationships are illustrated with reference toFIGS. 1-5, below.

FIG. 1 is a block diagram that illustrates a tree display form. Tree 100represents a data hierarchy using NetBeans Explorer, available from SunMicrosystems of Palo Alto, Calif. Tree 100 includes display elements102-150. Each display element has several properties. The single-valuedproperties include the name and icon. The multi-valued propertiesinclude the children, actions and referenced object properties. Thechildren property includes display elements that are displayed underanother display element. For example, the children property of displayelement 110 includes display elements 112 and 114. The “actions”property includes actions that may be performed on the display element.The actions may be displayed in a pop-up menu 152. As shown in FIG. 1,the actions available for display element 146 include Open 154,“Customize Bean” 156, Compile 158, Execute 160, Cut 162, Copy 164, New166, Delete 168, Rename 170 and “Save as Template” 172. The referencedobject properties are properties of the object represented by thedisplay element. As shown in FIG. 1, the properties for the objectrepresented by display element 146 are presented in a separate window174.

FIG. 2 is a block diagram that illustrates another tree display form.Tree 200 represents a file system displayed using Microsoft Explorer,available from Microsoft Corporation of Redmond, Wash. The properties ofdisplay element 202 include the actions that can be performed on thedisplay element, represented by pop-up menu 204. The properties ofdisplay element 202 also include the properties of the representedobject, represented by window 206.

FIG. 2 also illustrates a containment relationship. A containmentrelationship shows the objects contained by another object. Thisrelationship is typically displayed in the form of a tree. For example,folder beans 208 is “contained” by folder bdk1.1 (210) and folder bdk1.1(210) is contained by folder 212.

FIG. 3 is a block diagram that illustrates a cascade display form.Unlike the tree display form, cascade display form 300 has onlysingle-valued action attributes. The only action is the action performedwhen the user clicks on the element. The cascade display form 300 alsohas no referenced object properties. In other words, the cascade displayform 300 does not display properties of the object represented by thedisplay element.

FIG. 4 is a block diagram that illustrates a list display form. Listdisplay form 400 has the following single-valued attributes: displayname, icon and type. The type attribute values are displayed in column402. List display form 400 also includes a multi-valued “actions”attribute. The actions are for display element 404 displayed in pop-upmenu 406.

FIG. 5 is a block diagram that illustrates another list display form.Display form 500 is the same as display form 400 in FIG. 4, except thatlist display form 500 has no “Type” property.

Present day software applications typically lack the ability to displaymultiple types of object relationships. What is needed is a solutionthat enables the display of selected object relationships. A furtherneed exists for such a solution that is configurable and that providesfor multiple ways of viewing object relationships within the same net.

BRIEF DESCRIPTION OF THE INVENTION

A method for determining display element attribute values from an objectrepresented by the display element includes defining a display elementview including at least one elementary view that is capable ofdetermining a display element attribute value, receiving a displayelement attribute value request, determining the first view for thedisplay element and ascertaining at least one display element attributevalue for the display element based upon the first view. An apparatusfor determining display element attribute values from an objectrepresented by the display element includes a definer to define adisplay element view including at least one elementary view that iscapable of determining a display element attribute value, a receiver toreceive a display element attribute value request, a determiner todetermine the first view for the display element and an ascertainer toascertain at least one display element attribute value for the displayelement based upon the first view.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated into and constitute apart of this specification, illustrate one or more embodiments of thepresent invention and, together with the detailed description, serve toexplain the principles and implementations of the invention.

In the drawings:

FIG. 1 is a block diagram that illustrates a tree display form.

FIG. 2 is a block diagram that illustrates a tree display form.

FIG. 3 is a block diagram that illustrates a cascade display form.

FIG. 4 is a block diagram that illustrates a list display form.

FIG. 5 is a block diagram that illustrates a list display form.

FIG. 6 is a block diagram of a computer system suitable for implementingaspects of the present invention.

FIG. 7 is a block diagram that illustrates the relationship betweendisplay forms, display elements, represented objects and views inaccordance with embodiments of the present invention.

FIG. 8 is a block diagram that illustrates defining elementary andcomposite views in accordance with one embodiment of the presentinvention.

FIG. 9 is a block diagram that illustrates three views and associateddisplays of a Java™ program in accordance with one embodiment of thepresent invention.

FIG. 10 is a block diagram that illustrates displaying a view inaccordance with one embodiment of the present invention.

FIG. 11 is a block diagram that illustrates switching between views inaccordance with one embodiment of the present invention.

FIG. 12 is a block diagram that illustrates display elements havingdifferent views within the same display in accordance with oneembodiment of the present invention.

FIG. 13 is a block diagram that illustrates a system for displayingdisplay element attribute values in accordance with one embodiment ofthe present invention.

FIG. 14 is a flow diagram that illustrates a method for displayingdisplay element attribute values in accordance with one embodiment ofthe present invention.

FIG. 15 is a flow diagram that illustrates a method for determining adisplay element view in accordance with one embodiment of the presentinvention.

FIG. 16 is a flow diagram that illustrates a method for ascertainingdisplay element attribute values in accordance with one embodiment ofthe present invention.

FIG. 17 is a flow diagram that illustrates a method for ascertaining adisplay element attribute value using an elementary view in accordancewith one embodiment of the present invention.

FIG. 18A is a flow diagram that illustrates a method for ascertaining adisplay element attribute using a composite view in accordance with oneembodiment of the present invention.

FIG. 18B is a flow diagram that illustrates a method for searching viewscontained in a composite view in accordance with one embodiment of thepresent invention.

FIG. 18C is a flow diagram that illustrates a method for collectingattribute values for a display element using multiple views inaccordance with one embodiment of the present invention.

FIG. 19 is a flow diagram that illustrates a method for combining viewsto provide a more complete attribute set for display elements of aparticular type in accordance with one embodiment of the presentinvention.

FIG. 20 is a flow diagram that illustrates a method for adding values toa multi-valued attribute in accordance with one embodiment of thepresent invention.

FIG. 21 is a flow diagram that illustrates a method for combining viewsfor different display element types in accordance with one embodiment ofthe present invention.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

Embodiments of the present invention are described herein in the contextof a method and apparatus for determining display element attributevalues. Those of ordinary skill in the art will realize that thefollowing detailed description of the present invention is illustrativeonly and is not intended to be in any way limiting. Other embodiments ofthe present invention will readily suggest themselves to such skilledpersons having the benefit of this disclosure. Reference will now bemade in detail to implementations of the present invention asillustrated in the accompanying drawings. The same reference indicatorswill be used throughout the drawings and the following detaileddescription to refer to the same or like parts.

In the interest of clarity, not all of the routine features of theimplementations described herein are shown and described. It will, ofcourse, be appreciated that in the development of any such actualimplementation, numerous implementation-specific decisions must be madein order to achieve the developer's specific goals, such as compliancewith application- and business-related constraints, and that thesespecific goals will vary from one implementation to another and from onedeveloper to another. Moreover, it will be appreciated that such adevelopment effort might be complex and time-consuming, but wouldnevertheless be a routine undertaking of engineering for those ofordinary skill in the art having the benefit of this disclosure.

In the context of the present invention, the term “network” includeslocal area networks, wide area networks, the Internet, cable televisionsystems, telephone systems, wireless telecommunications systems, fiberoptic networks, ATM networks, frame relay networks, satellitecommunications systems, and the like. Such networks are well known inthe art and consequently are not further described here.

In accordance with one embodiment of the present invention, thecomponents, processes and/or data structures may be implemented using Cor C++ programs running on high performance computers (such as anEnterprise 2000™ server running Sun Solaris™ as its operating system.The Enterprise 2000™ server and Sun Solaris™ operating system areproducts available from Sun Microsystems, Inc. of Mountain View,Calif.). Different implementations may be used and may include othertypes of operating systems, computing platforms, computer programs,firmware, computer languages and/or general-purpose machines. Inaddition, those of ordinary skill in the art will readily recognize thatdevices of a less general purpose nature, such as hardwired devices,devices relying on FPGA (field programmable gate array) or ASIC(Application Specific Integrated Circuit) technology, or the like, mayalso be used without departing from the scope and spirit of theinventive concepts disclosed herein.

FIG. 6 depicts a block diagram of a computer system 600 suitable forimplementing aspects of the present invention. As shown in FIG. 6,computer system 600 includes a bus 602 which interconnects majorsubsystems such as a central processor 604, a system memory 606(typically RAM), an input/output (I/O) controller 608, an externaldevice such as a display screen 610 via display adapter 612, serialports 614 and 616, a keyboard 618, a fixed disk drive 620, a floppy diskdrive 622 operative to receive a floppy disk 624, and a CD-ROM player626 operative to receive a CD-ROM 628. Many other devices can beconnected, such as a pointing device 630 (e.g., a mouse) connected viaserial port 614 and a modem 632 connected via serial port 616. Modem 632may provide a direct connection to a remote server via a telephone linkor to the Internet via a POP (point of presence). Alternatively, anetwork interface adapter 634 may be used to interface to a local orwide area network using any network interface system known to thoseskilled in the art (e.g., Ethernet, xDSL, AppleTalk™).

Many other devices or subsystems (not shown) may be connected in asimilar manner. Also, it is not necessary for all of the devices shownin FIG. 6 to be present to practice the present invention, as discussedbelow. Furthermore, the devices and subsystems may be interconnected indifferent ways from that shown in FIG. 6. The operation of a computersystem such as that shown in FIG. 6 is readily known in the art and isnot discussed in detail in this application, so as not to overcomplicatethe present discussion. Code to implement the present invention may beoperably disposed in system memory 606 or stored on storage media suchas fixed disk 620, floppy disk 624 or CD-ROM 626.

According to embodiments of the present invention, views are defined forobjects comprising a net. A view determines display element attributevalues for an object represented by the display element. Elementaryviews may be combined to form composite views, with duplicate attributevalues removed. A view may be set for each display element.

FIG. 7 is a block diagram that illustrates the relationship betweendisplay forms, display elements, represented objects and views inaccordance with embodiments of the present invention. A display elementis an object or element used for representing an object. The representedobject depends upon the information being displayed. For example, theobjects in a file system display application may include files, and theobjects in a Java™ program display application may include a Java™class. As shown in FIG. 7, object 700 is represented by display elementsA 702, B 704 and C 706. Object 700 includes attributes 708, 710 and 712.Display element A 702 is associated with a tree form 714, whichdetermines the attributes for display element 702. Likewise, displayelement B 704 is associated with a table form 716, which determines theattributes for display element B 704. View A 718 is associated withdisplay element A 702 and view B 720 is associated with display elementB 704. Display element C 706 is not associated with a view and thus usesthe view of a related display element. Each view determines whichdisplay element attribute values are displayed for a particular displayelement.

FIG. 8 is a block diagram that illustrates defining elementary andcomposite views in accordance with one embodiment of the presentinvention. FIG. 8 includes net diagram 800 and three views 802, 804, 806that are based upon the net diagram 800. Net diagram 800 includes anobject 808 that represents a display element DE₁. Net diagram 800 alsoincludes several objects related to DE₁. Objects L₁ (810) and L₂ (812)have a first type of relationship with object 808. Objects M₁ (814), M₂(816) and M₃ (818) have a second type of relationship with object 808.Object M₄ (820) has the second type of relationship with object L₂(812).

According to embodiments of the present invention, attributes may besingle-valued or multi-valued. An example of a single valued attributeis descriptive information relating to the display element, such as aname. An example of a multi-valued attribute is a list of itemscontained by the display element (e.g. a list of child displayelements). Another example of a multi-valued attribute is actions thatmay be performed on a display element.

Still referring to FIG. 8, views 802, 804, 806 provide values of amulti-valued attribute named “children”. Elementary view 802 returnsobjects of type M as values of the “children” attribute. In this case,the returned objects include M₁ (814), M₂ (816) and M₃ (818). Elementaryview 804 returns objects of type L as values of the “children”attribute. The objects are L₁ (810) and L₂ (812). View 806 is acomposite view including views 802 and 804 and thus returns the resultof merging values returned from views 802 and 804. Thus, the objectsreturned for composite view 806 include M₁ (814), M₂ (816), M₃ (818), L₁(810) and L₂ (812).

Turning now to FIG. 9, a more specific example of defining views inaccordance with one embodiment of the present invention is presented.FIG. 9 is a block diagram that illustrates three views and associateddisplays of a Java™ program in accordance with one embodiment of thepresent invention. Net 900 illustrates relationships between objects ina Java™ program. ClassA 902 inherits from SuperClassA 904, as indicatedby parent-child (P-C) relationship 906. SuperClassA 904 inherits fromSuperClassC 906. ClassA 902 includes field 1 (908), field 2 (910),method 1 (912) and constructor 1 (914). Model 1 916 is a modelassociated with ClassA 924. ClassB 918 inherits from SuperClassB 920, asindicated by parent-child relationship 922. ClassB 918 includes field 3(924) and method 2 (926). Model 2 928 is a model associated with classB918.

Reference numerals 930, 932 and 934 represent three different views ofnet 900. Views 936, 938 and 940 provide values of a multi-valuedattribute named “subelement”. Elementary view 930 returns objects oftype “contained elements” as values of the subelement attribute.Elementary view 932 returns objects of type “model” as values of thesubelement attribute. Elementary view 934 returns objects of type“supertype” as values of the subelement attribute. Reference numerals936, 938, 940 represent displays corresponding to views 930, 932, 934,respectively. Thus, display 936 includes only objects of type “containedelements”, display 938 includes only objects of type “model” and display940 includes only objects of type “supertype”.

Views 930, 932, 934 are elementary views because they select only onetype of relationship. According to embodiments of the present invention,views may be configured by adding one or more views to another view. Byway of example, combining view 930 with view 934 creates a compositeview that includes contained display elements and supertype displayelements. Using the example illustrated in FIG. 9, such a composite viewis useful for determining the methods and fields that a class inheritsfrom its supertypes. Likewise, combining view 932 with view 934 createsa composite view that includes supertype display elements and associatedmodels.

FIG. 10 is a block diagram that illustrates displaying a view inaccordance with one embodiment of the present invention. As is common inthe art, clicking the right side of a mouse when an icon is selectedtypically results in a sub-menu display. The sub-menu display includesactions available with respect to the selected display element andactions available with respect to the object represented by the displayelement. In a file system, for example, attribute values 1000-1010 couldinclude actions such as “Copy”, “Cut”, “Paste”, “Delete” and “Rename”.According to one embodiment of the present invention, attribute valuessuch as the ones described above are combined into elementary views andone or more elementary views may be combined into a composite view.Either an elementary view or a composite view may be assigned to adisplay element.

Still referring to FIG. 10, elementary view 1 (1014) returns a firsttype of object value as values for the “actions” attribute. Attributevalue 1A (1000) and attribute value 1B (1002) belong to this firstobject type. Elementary view 2 (1016) returns a second type of objectvalue as values for the “actions” attribute. Attribute value 2A (1004)and attribute value 2B (1006) belong to this second object type.Elementary view 3 (1018) returns a third type of object value as valuesfor the “actions” attribute. Attribute value 3A (1008) and attributevalue 3B (1010) belong to this third object type. Composite view 1(1020) includes elementary views 1014, 1016 and 1018 and composite view1022 includes elementary views 1016 and 1018. Thus, for example, when adisplay element associated with composite view 2 (1022) is selected, theresulting menu would display values for the second and third objecttype, namely, attribute values 2A (1004), 2B (1006), 3A (1008) and 3B(1010). The objects represented by display elements 1024, 1026 and 1012may be associated with separate views.

According to embodiments of the present invention, a composite view maybe changed dynamically. A composite view may be changed by adding one ormore elementary or composite view or by removing one or more elementaryor composite view included in the composite view.

FIG. 11 is a block diagram that illustrates switching between views inaccordance with one embodiment of the present invention. FIG. 11includes a containment view 1100 of Java™ package MyPackage 1102 and aninheritance view 1104 of the same package. MyPackage 1102, 1106corresponds with net 900 of FIG. 9. In the example illustrated by FIG.11, display element MyPackage 1102 is initially associated with acontainment view 1100. Thus, expanding the display element results in adisplay that includes all contained items. MyClassA 1108 contains field1 (1110), field 2 (1112), method 1 (1114) and constructor 1 (1116).MyClassB 1118 is unexpanded in FIG. 11.

Still referring to FIG. 11, a user changes the view associated withdisplay element MyPackage 1102 from a containment view 1100 to aninheritance view 1104. Unlike containment view 1100, inheritance view1104 shows all items from which a display element inherits. MyClassA1120 inherits from SuperClassA (1122). SuperClassA (1122) inherits fromSuperClassC (1124) and SuperClassC (1124) inherits from java.lang.Object1126.

The illustration of containment views and inheritance views is forpurposes of illustration and is not intended to be limiting in any way.Those of ordinary skill in the art will recognize that other views maybe used.

FIG. 12 is a block diagram that illustrates display elements havingdifferent views within the same display in accordance with oneembodiment of the present invention. Display element MyPackage 1200corresponds with net 900 of FIG. 9. FIG. 12 includes an initial display1202 and an expanded display 1204. Display element 1206 is associatedwith an inheritance view 1210 and display element 1208 is associatedwith a containment view 1212.

Expanding display element 1206 results in a display that includes allitems from which MyClassA 1206 inherits. As shown in FIG. 12, MyClassA1206 inherits from SuperClassA 1214. SuperClassA 1214 inherits fromSuperClassC 1216 and SuperClassC 1216 inherits from java.lang.Object1218. Expansion of display element MyClassA 1206 begins with examiningthe view associated with display element MyClassA 1206. In the presentexample, MyClassA 1206 is associated with an inheritance view. Thus,SuperClassA 1214 is displayed. Next, SuperclassA 1214 is selected forexpansion and the view associated with display element SuperClassA 1214is examined. According to one embodiment of the present invention, adisplay element uses the view associated with the closest parent displayelement when the display element has no view directly associated withit. Thus, if display element SuperClassA 1214 has a view associated withit, that view is used to determine what to display. If display elementSuperClassA 1214 has no view associated with it, the view associatedwith its parent display element (MyClassA 1206) is used to determinewhat to display. This process continues for display element SuperClassC1216 and display element java.lang.Object 1218 when the display elementsare selected for expansion.

Still referring to FIG. 12, display element MyClassB 1208 is associatedwith a containment view 1212 and thus the expanded display for displayelement MyClassB 1208 includes all items contained by MyClassB 1208. Asshown in FIG. 12, MyClassB 1208 includes field 3 (1220) and method 2(1222).

Turning now to FIG. 13, a block diagram that illustrates a system fordisplaying display element attribute values in accordance with oneembodiment of the present invention is presented. Display system 1300includes a receiving interface 1302 for receiving user input 1304, aview definer 1306 for defining a view based upon user input 1304, a viewchanger 1308 for changing a view and a view determiner 1310 fordetermining the view associated with a display element. Display system1300 also includes a value ascertainer 1312 for ascertaining the valuesassociated with display element attributes using a particular view and adisplay interface 1314 to display the display element attribute valueson display device 1322. Object database 1316 stores object valuesincluding attribute data and view database 1318 stores views associatedwith display elements.

In operation, view definer 1306 receives view definitions from a user1320 via receiving interface 1302 and stores the view definitions inview database 1318. View determiner 1310 receives a display elementattribute value request from a user via receiving interface 1302 andobtains the view associated with the display element from view database1318. Value ascertainer 1312 receives a display element and associatedview from view determiner 1310 and ascertains values for each attributedefined in each elementary view from object database 1316 and forwardsthe results to display interface 1314. Display interface 1314 receivesthe attribute values from view value ascertainer 1312 and formats thedata for display on display device 1322. View changer 1308 accepts aview modification from user 1320 via receiving interface 1302 and storesthe modified view in view database 1318 for subsequent display ondisplay device 1322. According to other embodiments of the presentinvention, view definitions and view modifications are received from acomputer program.

Turning now to FIG. 14, a flow diagram that illustrates a method fordisplaying display element attribute values in accordance with oneembodiment of the present invention is presented. At 1400, displayelement views are defined. Views may set for one or more displayelements, each of which is tied to a particular display form. Views maybe defined for one or more kind of display element.

At 1402, a display element attribute value request is received. Forexample, suppose a file browser application tree form requires “name”and “icon” values for each root display element when the file browserapplication begins. In this case, a request for “name” attribute valuesor “icon” attribute values is received at 1402. Continuing the filebrowser example, suppose that the tree form requires values for a“children” attribute when a folder is expanded. Here, a request for“children” attribute values is received at 1402. Likewise, suppose thefile browser application tree form requires “action” attribute valueswhen a user right-clicks on a display element. In this case, a requestfor “action” attribute values is received at 1402.

At 1404, the view defined for the selected display element is determinedby extracting a view definition from a view database. At 1406, thedisplay element attribute values requested at 1402 ascertained, usingthe view determined at 1404. At 1408, the attribute values determined atreference numeral 1406 are displayed on a display device. At 1410, adetermination is made regarding whether there are more display elements.If so, processing continues at reference numeral 1402.

According to one embodiment of the present invention, a display elementthat is not associated with a view uses the view associated with arelated display element to determine which display element attributevalues are displayed. The related display element may be, by way ofexample, a “parent” display element. This embodiment is described inmore detail below with reference to FIG. 15.

Turning now to FIG. 15, a flow diagram that illustrates a method fordetermining a display element view in accordance with one embodiment ofthe present invention is presented. FIG. 15 provides more detail withrespect to reference numeral 1402 of FIG. 14. At 1500, a determinationis made regarding whether a view is defined for the display element. Ifa view is defined for the display element, at 1502, the display elementview to use is set to the view defined for the display element. If aview is not defined for the display element, at 1504, the displayelement view to use is set to the view associated a parent displayelement.

Turning now to FIG. 16, a flow diagram that illustrates a method forascertaining display element attribute values in accordance with oneembodiment of the present invention is presented. FIG. 16 provides moredetail with respect to reference numeral 1404 of FIG. 14. At 1600, adisplay element attribute is received. At 1602, a determination is maderegarding whether the view is an elementary view or a composite view. Ifthe view is an elementary view, at 1604, the display element attributevalue is ascertained using the elementary view. If the view is acomposite view, at 1606, the display element attribute value isascertained using the composite view. At 1608, a determination is maderegarding whether another display element attribute remains to beprocessed. If another display element attribute remains, processingcontinues at 1600.

Turning now to FIG. 17, a flow diagram that illustrates a method forascertaining a display element attribute value using an elementary viewin accordance with one embodiment of the present invention is presented.FIG. 17 provides more detail with respect to reference numeral 1604 ofFIG. 16. At 1700, a request for display of display element attributevalue within an elementary view is received. At 1702, a determination ismade regarding whether the elementary view is compatible with the objectrepresented by the display element. At 1704, a determination is maderegarding whether there is a value defined for the attribute. If theelementary view is incompatible with the represented object, or if thereis no value defined for the attribute, at 1706, an indication that novalue is defined for the attribute is returned. If the elementary viewis compatible with the represented object and if there is a valuedefined for the attribute, at 1708, a determination is made regardingwhether the attribute is multi-valued. If the attribute issingle-valued, the attribute value is returned at 1710. If the attributeis multi-valued, the attribute values are returned at 1712.

Turning now to FIG. 18A, a flow diagram that illustrates a method forascertaining a display element attribute using a composite view inaccordance with one embodiment of the present invention is presented.FIG. 18A provides more detail with respect to reference numeral 1606 ofFIG. 16. At 1800, a request for display of display element attributevalue within a composite view is received. At 1802, a determination ismade regarding whether the attribute is multi-valued. If the attributeis single-valued, at 1804, the contained views are searched in apredefined order and the first occurrence of a value for the particularattribute is returned. If the attribute is multi-valued, at 1806, allvalues for the particular attribute are collected for each containedview. At 1808, the results from reference numeral 1806 are mergedtogether and returned.

FIG. 18B is a flow diagram that illustrates a method for searching viewscontained in a composite view in accordance with one embodiment of thepresent invention. FIG. 18B provides more detail for reference numeral1804 in FIG. 18. At 1810, a view contained within a composite view isreceived. At 1812, a determination is made regarding whether the view isan elementary view. If the view is a composite view, at 1814, thedisplay element attribute value is ascertained using the composite view.If the view is an elementary view, at 1816, the display elementattribute value is ascertained using the elementary view. If a value wasfound as a result of the processes at 1814 or 1816, the value isreturned at 1820. If a value was not found, the next view is processedat 1810. This process continues until a value is found, or until all thecontained views have been examined.

FIG. 18C is a flow diagram that illustrates a method for collectingattribute values for a display element using multiple views inaccordance with one embodiment of the present invention. FIG. 18Cprovides more detail for reference numeral 1806 in FIG. 18. FIG. 18C issimilar to FIG. 18B, except that the process illustrated by FIG. 18Cdoes not stop after finding a value. Instead, the returned values forall contained views are collected before returning a set of values for amulti-valued attribute at 1844.

Composite views may be used for several purposes in accordance withembodiments of the present invention. Composite views may be used, byway of example, to provide a more complete set of attributes for aparticular display element type, to extend the options available forexisting multi-valued attributes, or to provide a view that can be usedfor different display element types. These embodiments are described inmore detail below, with reference to FIGS. 19-21. FIGS. 19-21 illustratethree different applications of the method illustrated by FIG. 18B.

According to one embodiment of the present invention, multiple views maybe combined to provide a more complete set of attributes for aparticular type of display element. As mentioned above, the set ofdisplay element attributes is predetermined based on the display form.However, a view may be defined to return attribute values for any numberof the attributes. For example, suppose the set of display elementattributes for a particular display element is (name, icon,sub-elements) and that view V1 provides the name attribute, view V2provides the icon attribute and view V3 provides sub-elements. Combiningviews V1, V2 and V3 creates a composite view that provides a morecomplete set of attributes (name, icon, sub-elements) for the particulartype of display element. This embodiment of the present invention isdescribed below in more detail with reference to FIG. 19.

Turning now to FIG. 19, a flow diagram that illustrates a method forcombining views to provide a more complete attribute set for displayelements of a particular type in accordance with one embodiment of thepresent invention is presented. At 1900, a first view for a displayelement is received. At 1902, a second view for the same display elementis received. The second view includes at least one display elementattribute that is not found in the first view. At 1904, the first viewand the second view are combined to create a third view. At 1906, thethird view is used for the display of display element attribute values.

According to another embodiment of the present invention, compositeviews may be used to extend the options available for existingmulti-valued attributes. For example, suppose elementary view V1provides popup menu actions for clipboard operations (cut, paste, copy,etc.) on a particular type of display element, and that view V2 providesactions for deleting and creating new objects for the same type ofdisplay element. Combining views V1 and V2 creates a composite view thatextends the popup menu actions for a particular type of display element.

As another example of the above embodiment, consider a file browser thatdefines a set of views for files and folders. The file browserapplication has a composite view that contains the various views and thecomposite view is associated with all files and folders. According tothis embodiment of the present invention, adding a new functionality isaccomplished by adding a new elementary view that includes the newfunctionality to the composite view. Thus, by way of example, adding theability to pack or unpack files and folders using ZIP compression isaccomplished by creating an elementary view that includes the “pack” and“unpack” actions and then adding the new elementary view to thecomposite view. This embodiment of the present invention is describedbelow in more detail with reference to FIG. 20.

Turning now to FIG. 20, a flow diagram that illustrates a method foradding values to a multi-valued attribute in accordance with oneembodiment of the present invention is presented. At 2000, a compositeview is received. The composite view includes at least one multi-valuedattribute. At 2002, an elementary view that includes at least oneadditional value for the same multi-valued attribute is added to thecomposite view, providing a modified composite view that returns aricher set of actions for a particular display element type. Using theexample above, the first view is the original composite view and theelementary view includes the pack and unpack actions. At 2004, themodified composite view is used for the display of display elementattribute values.

According to another embodiment of the present invention, compositeviews may be used to provide a view that can be used for differentdisplay element types. For example, suppose a program displayapplication is used to display a program written in Java™ and C++. ViewV1 returns properties for Java™ classes and view V2 returns propertiesfor C++ classes. A composite view containing both V1 and V2 can be usedto represent both types of classes. This embodiment of the presentinvention is described below in more detail with reference to FIG. 21.

Turning now to FIG. 21, a flow diagram that illustrates a method forcombining views for different display element types in accordance withone embodiment of the present invention is presented. At 2100, a firstview for a first display element is received. At 2102, a second view fora second display element is received. At 2104, the first view and thesecond view are combined. At 2106, the third view is used for thedisplay of display element attribute values.

Embodiments of the present invention provide a number of importantadvantages. Allowing views that are configurable for each displayelement in a net provides added flexibility. This capability allowsusers to tailor a view of a system according to their particularrequirements, and to change the view dynamically.

While embodiments and applications of this invention have been shown anddescribed, it would be apparent to those skilled in the art having thebenefit of this disclosure that many more modifications than mentionedabove are possible without departing from the inventive concepts herein.The invention, therefore, is not to be restricted except in the spiritof the appended claims.

What is claimed is:
 1. A method for determining display elementattribute values for a display element that represents an object in acomposite view, the composite view containing a plurality of views, thedisplay element having at least one attribute associated therewith, eachattribute having at least one attribute value, said method comprising:receiving a display element attribute value request; determining thecomposite view for the display element based upon the display elementattribute value request; and ascertaining at least one attribute valuefor the display element based upon the composite view, wherein saidascertaining comprises: when the attribute is single-valued, searchingeach of the plurality of views contained in the composite view for avalue for the attribute and returning the value; and when the attributeis multi-valued, collecting all values for the attribute for each of theplurality of views contained in the composite view, merging the valuesobtained by said collecting, and returning the merged values.
 2. Aprogram storage device readable by a machine, embodying a program ofinstructions executable by the machine to perform a method fordetermining display element attribute values for a display element thatrepresents an object in a composite view, the composite view containinga plurality of views, the display element having at least one attributeassociated therewith, each attribute having at least one attributevalue, said method comprising: receiving a display element attributevalue request; determining the composite view for the display elementbased upon the display element attribute value request; and ascertainingat least one attribute value for the display element based upon thecomposite view, wherein said ascertaining comprises: when the attributeis single-valued, searching each of the plurality of views contained inthe composite view for a value for the attribute and returning thevalue; and when the attribute is multi-valued, collecting all values forthe attribute for each of the plurality of views contained in thecomposite view, merging the values obtained by said collecting, andreturning the merged values.
 3. An apparatus for determining displayelement attribute values for a display element that represents an objectin a composite view, the composite view containing a plurality of views,the display element having at least one attribute associated therewith,each attribute having at least one attribute value, said apparatuscomprising: means for receiving a display element attribute valuerequest; means for determining the composite view for the displayelement based upon the display element attribute value request; andmeans for ascertaining at least one attribute value for the displayelement based upon the composite view, wherein said means forascertaining comprises: means for, when the attribute is single-valued,searching each of the plurality of views contained in the composite viewfor a value for the attribute and returning the value; and means for,when the attribute is multi-valued, collecting all values for theattribute for each of the plurality of views contained in the compositeview, merging the values obtained by said collecting, and returning themerged values.
 4. An apparatus for determining display element attributevalues for a display element that represents an object in a compositeview, the composite view containing a plurality of views, the displayelement having at least one attribute associated therewith, eachattribute having at least one attribute value, said apparatuscomprising: a receiving interface to receive a display element attributevalue request; a view determiner to determine the composite view for thedisplay element based upon the display element attribute value request;and a value ascertainer to ascertain at least one attribute value forthe display element based upon the composite view, wherein said valueascertainer is configured to: when the attribute is single-valued,search each of the plurality of views contained in the composite viewfor a value for the attribute and return the value; and when theattribute is multi-valued, collect all values for the attribute for eachof the plurality of views contained in the composite view, merge thevalues obtained by said collecting, and return the merged values.